ext4数据恢复实战及文件系统结构详解

　　如果你的数据被不小心误删除了，那么对文件系统结构的深入理解可以帮助你找到数据恢复的途径。我们先从一个数据恢复的例子开始，对ext4的文件系统结构做个介绍。

　　废话少说，下面我们直接上手进行数据恢复的实例。先格式化一个ext4文件系统。

　　挂载到测试目录：

　　/test是我们这次做测试的目录。我们给这个目录下创建一些文件，为了文件内容比较好分辨，我们使用/etc/下的文件作为测试文件。因为都是普通文本文件，肉眼比较方便区分文件内容。

　　为了恢复测试方便，我们使用passwd文件的内容，手工做一个比较大的文本文件：

　　这样我们就有了一个2G左右的文件，等下我们就删除这个文件，再来恢复它的数据。 　　再删除他之前，我们先记录一些文件的信息，以方便我们后续针对测试进行数据对比，先学习使用一个命令debugfs来查看ext4文件系统的相关信息：

　　可以显示出文件的inode编号对应文件名的信息。在其中找到我们的bugfile：189 (1420) bigfile，看到它的inode编号为189。然后使用这个编号来查看文件相关其他信息：

　　stat命令可以查看文件inode信息，最后面的EXTENTS标记的内容就是这个文件目前索引的block编号。

　　ex命令可以查看更详细的EXTENTS的映射关系。在此我们先不对EXTENTS信息作详细解释，后续恢复数据的时候我们再说。

　　imap命令可以查看一个inode所在的block位置和其偏移量，就是说，利用这个信息我们就可以找到这个inode在当前磁盘的什么位置，比如这个例子就是：189号inode在当前磁盘的1301个块上再偏移0x0c00字节。那么当前分区一个block多大？一个inode多大呢？

　　通过stats命令我们可以查看文件系统的superblock，其中记录了文件系统的属性信息。当前文件系统的block size为4096，inode size为256。 　　根据以上信息，我们可以将189号inode的二进制数据dump出来：

　　产生的这个文件就是189号inode的磁盘二进制数据。当然这是未删除文件前的，我们等下再删除文件后建一个新的，以对比删除前后两个inode的变化。 　　我们回到debugfs命令，然后看一下文件的block内容，以确认文件内容：

　　可以看到，文件对应的block信息确实是passwd的相关数据。 　　之后，我们可以删除文件了，然后使用debugfs再观察文件信息：

　　这时要使用ls -d参数，显示包括已删除文件在内的所有inode信息，其中所有带有标示的inode编号都是已经被删除的文件，但此时，仍然可以用debugfs看到对应inode信息。 　　然后我们继续在debugfs中使用其他命令查看188号inode的信息：

　　我们发现，此时inode中数据除了EXTENTS信息没了以外，其他相关信息还能找到。理想情况下，我们刚删除一个文件，在较短时间进行恢复的话，就应该是这样一个状态。于是，我们开始尝试恢复数据，仍然是根据imap信息，先dump出文件的inode进行查看：

　　此时我们有两个inode数据，一个是文件删除前的，一个是文件删除后的。为了后续我们查看inode内容方便，我们先要补充inode数据结构的相关知识。ext4 inode结构可以在内核源代码目录下的 fs/ext4/ext4.h 文件中找到。我们来看一下：

　　inode结构信息并未显示完整，我们只选取我们当前关注的信息进行学习。在这个结构体中我们可以看到，文件的相关属性信息都在inode中，这里对于数据恢复最重要的是i_block数组，这个数组中有15个元素，记录的是此文件指向的存储文件数据的对应block。在ext2/3文件系统上，这个数组的前12的元素是直接指向存储数据的block，恢复数据可以直接读对应编号的block即可。而13、14、15三个分别为一级、二级、三级间接索引指向，相关概念不在此详述，但是相对比较容易找到对应的block查看相关数据。 　　而我们目前面对的是ext4，在数据block索引方法上相对ext3有很大变化，主要就是引入了extent机制。我们在此不详述为啥要引入extent，仅从数据恢复的角度来学习extent的结构。那么针对当前这个2G左右的文件，其extent在inode上是怎么布局的呢？可以参考下图：

　　在ext4_inode结构中，存储extents相关数据结构的位置实际就是i_block数组所在的位置，因为ext4是使用extent索引磁盘block的，所以直接复用i_block空间即可。extents相关数据结构有三种，所有数据结构原型声明都在内核源代码目录下fs/ext4/ext4_extents.h 文件中，我们来看一下：

　　根据途中的索引关系我们可以知道，实际索引block信息的是 ext4_extent 数据结构。因为ext4支持48位块，所以在这个结构中用三个记录了指向的块，其中 ee_start_hi 和 ee_start_lo 两个组合起来记录了48位的物理第一块编号，ee_len 记录了从第一个块之后多少块都是属于这个extent连续数据块。以此可知，因为 ee_len 只有16bit，而且其首个bit被用来标记次extent是否被初始化，所以单独一个ext4_extent最多可以索引的连续块长度为2^15 * 4096(block 长度) = 128M空间。 　　我们根据inode的内容再来看一下其他数据结构的含义：

　　使用hexdump命令按照每行8个数据每个数据4字节长度来对比看一下文件删除后和删除前的inode信息。根据inode结构我们可以推算出，第40字节数据开始处是i_block存储位置。根据对应数据结构细节和布局图可知，一个ext4_extent_header占12字节，一个ext4_extent_idx占12字节。针对如上描述，可知对应位置每四字节的数据为： 　　删除后：

　　删除前：

　　对比发现，此inode信息的ext4_extent_idx没有被清除，而ext4_extent_header信息在删除后有被改动。我们丢失了比较关键的eh_depth信息，这个信息记录了这个文件extents树的层级个数，这会影响后续数据恢复的过程。如果知道这个层级个数，恢复会更容易一些，不知道的话就要靠猜测了。 　　不过针对我们当前这个文件，因为删除前我们备份了inode信息，所以可以找出这个eh_depth层级数为1。

　　显示中对应第二行第八个数字为eh_depth值。可以看到这个值在删除后被清0了。 　　不过最关键的索引信息在ext4_extent_idx中，ei_leaf_lo的值为34816，不过因为要记录的是48bit块，所以其后面的16bit还可能记录着高16bit的block编号数据。再看hexdump -e ‘“%4_ad |” 16/2 "%5d " “\n”’ 5331968.rm 显示中的第二行倒数第三个数，就是ei_leaf_hi，值为0。意味着34816就是下一级extent结构。所以我们dump出这个块来继续分析：

　　因为已知这个文件extent树只有1级，所以我们可以大胆的根据下一级结构对索引的block进行估算。再上图中，这个block内容对应这个布局：

缺图

　　我们猜测上述blcok的hexdump内容在6-12行为有效数据，即偏移量标示为0-224字节内的所有内容。前12个字节为ext4_extent_header信息。使用 hexdump -e ‘“%4_ad |” 16/2 "%5d " “\n”’ 34816 命令可以看到这个header中对应的eh_depth为0，所以12字节后的都是ext4_extent结构，直接指向对应block。ext4_extent中，我们主要关注ee_len、ee_start_hi、ee_start_lo，并且后两个组合在一起表示一个48位block信息。所以我们先用下面这个命令列出所有的ext4_extent中的起始block位置的低32位数字：

　　以上除第一列偏移字节数以外的第三列数字就是起始block位置的低32位数字。然后我们再列出高16位数字：

　　以上除第一列偏移字节数以外的第四列数字就是起始block位置的高16位数字。全是0，就是说目前所有的block编号32bit长度就可以记录了，没用到高16bit，所以我们直接使用32位数字作为每个分段的起始block位置即可。每个分段的连续长度是这里显示的第三列，但是这16bit中，最高一个bit用来标记本extent是否被占用，所以我们只看后15bit。于是碰巧，这列中的数字取绝对值就是这个分片的blocks个数。 　　由此我们可以得出这个文件所有block在磁盘上的覆盖范围，并保存到block_list文件中：

　　第一列为分片起始磁盘block，第二列为这个分片连续的块个数。 　　使用这个文件的内容恢复文件数据：

　　一个2G大小的文件内容恢复完成。当然，我们在这里选择恢复一个2G大小的文件是有原因的。目前我们发现，文件比较小时侯，inode中的extent可以直接指向extent块，并且在删除文件的时候，这部分extent信息会被清零，导致索引块信息丢失。而有多级索引的extent信息却可以被保留下来，虽然也丢失了部分信息，但是依然可以通过残留的部分信息对文件进行恢复。

　　根据上面的例子，我们已经对文件inode的结构和extent索引结构有了一定了解。接下来我们来补充一下ext4整个文件系统的相关知识。

　　ext4的分区结构布局跟ext3基本没什么变化，结构参见下图：

缺图

　　这里跟ext3有变化的是绿色标记的部分：ext4加入了flex_bg属性，这个属性让文件系统在块组结构之上又多了个flex块组结构。每个flex_bg包含连续的若干个块组，这个功能让之前分散在各个块组中管理的组描述符、块位图、inode位图和inode表等相关metadate信息放在了flex_bg的第一个块组中管理，于是其他块组中基本都是连续的块。 　　我们可以使用dumpe2fs命令查看ext4文件系统的结构，其中Flex block group size就是一个flex_bg中包含的块组个数：

超级块（superblock）： 　　就是我们在dumpefs现实中看到的前些行块组信息以外的内容。记录了整个文件系统的块大小、inode大小、块、inode个数、日志块等关键属性信息。

组描述符（Group descriptors）： 　　存储了本块组内相关块的位置，比如块位图、inode位图、inode table等。内核中相关结构体定义如下：

保留的全局描述符表（Reserved GDT）： 　　这部分空间一般用来给文件系统进行空间拓展的时候使用。当空间拓展的时候，由于新空间的加入可能导致组描述变大，用这部分空间进行扩展。

块位图（Block bitmap）： 　　用位图方式标记每一个块是否被占用。

inode位图（Inode bitmap）： 　　用位图方式标记每一个inode是否被占用。

inode表（Inode table）： 　　用来存放所有inode，每个inode在当前文件系统上是256字节。在超级块中的Inode size记录每一个inode大小。 　　在ext4文件系统上，以上数据结构在flex_bg中是集中存放在第一个块组中的。其余块组中可以不用记录相关信息，都集中存放block。在ext3上相关信息是分散在每一个块组中。

　　当我们mount一个ext4文件系统的时候，此文件系统的第一个inode会跟要要挂载的目录inode编号进行关联。而目录的inode中索引的block存放这个目录的目录项信息。每一个目录项纪录了下一级目录或文件的inode编号，于是就可以遍历到文件系统中所有的目录和文件。 我们可以在挂载文件系统前后来观察对应挂载目录的inode编号变化：

　　挂载前，mnt目录的inode编号为917505。挂载一个分区之后，对应的inode编号变为2。对于一个ext4文件系统来说，第一个inode编号总为2。我们可以通过debugfs命令来查看其相关信息：

　　从extent信息中我们可以看到，这个inode的Flags为0x81000，表示其使用了dir_index方式存储目录项。所以我们不能再以直接查看9482块的内容方式查看其目录项。先通过htree，命令查看其index结构：

　　由于其用了dir_index，其第一个block变成了index_block。第一个block是9482。我们查看这个block内容：

　　这个块起始于一个dx_root结构体，相关代码在内核源代码 fs/ext4/namei.c 文件中，定义为：

　　本目录的dx_entry管理了2个block，一共需要16个字节的内容，block内容的第三行就是dx_entry存储开始的位置： 　　fc01 0200 ：hash值 　　0100 0000 ：block编号 　　4efd e28d ：hash值 　　0200 0000 ：block编号 　　这个block后续内容已经废弃，所以不用继续看了。dx_root各个字段大家可以参照结构体内容分别对应研究一下，此处不在过多讲解。 　　这里要额外说明的是，dir_index功能会在目录索引的block超过一个之后默认开启，其目的是为了在目录下存放的文件或者子目录过多的时候以hash的方式加快block索引速度。这样要比直接线性存放目录项的索引速度要快，目录下的文件越多，效果比线性存放目录项越好。 　　之后，对应的下一级文件或目录名就会以hash的方法分别放在另外两个块中。我们看一下其中一个block的内容：

　　这时block中存放的就是目录项的内容。每个单独的目录项结构如下：

　　block最开始记录了lost+found的目录项，注意其子节序为intel byte，是小端字节序。分析其内容可知： 　　0b00 0000：inode编号，11 　　1400 ：目录项长度，20字节 　　0a：目录名长度，10字节 　　02 ：文件类型，2表示目录，1表示普通文件 　　后续就是文件/目录名的字符串存放位置。此处要注意的是，每个目录项都会按照4字节对齐，所以名字字符串后面还可能有0填充对齐。 　　后续的文件名我们就不挨个分析了。如果没启用dir_index的话，inode索引block的内容直接线性存放的这种的结构。

　　我们来删除一个目录，来观察一下目录的inode信息变化。我们想要操作分区上的yum目录。其inode编号为：

　　查看其inode的结构内容：

　　我们观察到，这个目录因为内容比较少，所以只占用了一个block，所以flags显示并没启用dir_index。inode中也直接记录了其索引的block编号。我们删除这个目录再来观察一下inode内容：

　　inode中的block编号纪录已经被删除。我们创建一个内容比较多的目录，尽量让其占用很多的block，再来看看效果：

　　此时目录已经启用了dir_index，观察inode信息，我们发现虽然其一共索引了480个block，但inode中只纪录了第一个block，其他block都是由第一个block中记录的hash tree进行索引的。我们删除这个目录再观察：

　　第一个block的索引已经在删除之后被清除了。从这个实验可以看出来，我们是无法通过inode相关信息恢复目录相关信息的。即使找到第一个块，也无法通过其hash tree恢复相关内容，因为hash tree里只有逻辑块编号，并没有物理块编号。 　　对于ext4系统来说，我们基本无法通过inode和dir_index相关索引信息恢复目录树结构。

　　通过目录的每一级索引，就可以遍历到文件系统上所有文件的inode编号，进而找到对应的inode信息。我们已经知道inode中索引了相关block信息，于是整个文件系统所存储的数据就这样组织起来了。 　　我们通过开头的实验已经大概知道inode中如何索引的block，但那是对一个2G的大文件。如果文件比较小，那么其extent的索引结构相对比较简单。我们知道inode中存放i_block索引的数组元素个数是15个，每个是一个int，所以一共有60字节的长度可以用来存放extent相关数据结构。对于小文件的情况，起索引结构如下图：

缺图

　　每个ext4_extent_header和ext4_extent结构都是12字节。所以这部分最多可以存4个ext4_extent索引，每个ext4_extent最多可以索引32768个连续的block。所以理论上，通过inode直接索引的文件大小最大可以达到512M长度。但是现实使用的情况下，磁盘上一般都不会有那么多连续的块分配给文件，所以大多数文件都到不了这么长，只要占用的ext4_extent结构超过4个，就会产生分级的extent进行更多的块索引。 　　如果是这种小文件inode直接索引block，在文件被删除的时候，inode中的extent数据结构都会被清零。所以，这种直接索引的文件，也无法通过inode中残留的信息找回相关数据。 　　以上是普通的文本文件的inode结构。Linux中文件类型除了目录和普通文件以外，还包括符号连接、块设备、字符设备、管道文件和socket文件。这些特殊类型文件大多数不会通过extnet索引块纪录相关信息，相关信息都直接被记录在inode中。比如符号连接，因为它只是纪录了到其指向文件的路径，所以其路径信息会直接记录在i_block数组中。我们可以通过以下命令来查看符号连接的inode内容：

　　除非符号连接中记录的文件路径在i_block数组位置中记录不下了，才会索引一个块来记录相关内容。其他特殊文件机制类似，而这种文件在删除的时候，inode中的数据会像小文件一样被清0，所以我们也无法通过同样的思路恢复这些特殊类型文件。

　　至此，我们通过一个文件的数据恢复的实例对ext4文件系统的整体结构做了介绍。并介绍了通过文件系统结构和inode结构恢复数据的原理。但这种数据恢复思路依然有其局限性，比如小文件无法恢复、特殊文件无法恢复、目录树结构无法恢复。在有数据持续写入的情况下，被误删除的大文件索引的block也有可能被其他数据覆盖，所以实际在恢复数据的过程中会因这种情况导致数据恢复不完整。我们还可以通过对文件系统块进行全部扫描的方式，来通过文件头部的特征码找到部分占用1个block以内的小文件进行恢复。 　　数据恢复技术是一个复杂的技术，在实际的恢复过程中会遇到各种各样的问题。希望本文可以通过ext4文件系统的结构视角对理解数据恢复技术有一定帮助。